MediaWiki talk:Common.css/Archive 10

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 8

→

.references-small font-size

I have posed this question in Template talk:Reflist#Font-size (in IE). I would like to change the font-size for .references-small to 88%, as opposed to the curreent 90%. The reason being that 90% isn't actually smaller in IE, and changing it would bring IE in line with other browsers. See Template:Reflist/testcases for the result.

As a unrelated note, I've removed ol.references { font-size: 100%; } as it does nothing; there is no previous font-size declaration for that class, so it is completely useless. It was once changed from 90% to 100% before {{reflist}} came into existence. — Edokter • Talk • 15:43, 12 May 2009 (UTC)

support both. ---— Gadget850 (Ed) ^talk 17:32, 12 May 2009 (UTC)

support both —TheDJ (talk • contribs) 18:44, 12 May 2009 (UTC)

The smaller text-size in firefox was introduced (under protest) with the motivation that it would make firefox's multiple columns {{reflist}} look less cramped. I fail to see why you would want to reduce the text-size in this case, especially since (as you point out over at reflist talk) it makes it harder to read for some people? I think it's fair to assume that older people who typically doesn't have as great eyesight might also use IE to a higher extent (not everyone of course but still). So the impact from small text in FF might not be as noticeable. Anyway, why not bring the textsize in FF back up to IE size instead? I'd prefer accessible to more people rather than small text when it's possible?
—Apis (talk) 04:55, 13 May 2009 (UTC)

If this is only supposed to be applied to multicolumn references, then the implementation is incorrect altogether, you should make a proposal to use more intelligent CSS/template for that. —TheDJ (talk • contribs) 10:57, 13 May 2009 (UTC)

Yes, I agree. But I don't really agree with the motivation in the first place.
—Apis (talk) 14:45, 13 May 2009 (UTC)

Because you can't really change the font size in discrete increments. In IE, 90% is the same as 100%; in FF, 88% is the same as 90%; setting the font size to 88% reduces the size for both browsers which was the original intent. For example:

This is 88% font size
This is 90% font size
This is 100% font size

---— Gadget850 (Ed) ^talk 10:39, 13 May 2009 (UTC)

BTW, on Safari Mac OSX, all three are different font-sizes for me. I get 11, 12 and 13px respectively. —TheDJ (talk • contribs) 10:57, 13 May 2009 (UTC)

Actually, mostly 90 and 88 are the same, it just seems that in same rare layout cases, Safari suddenly seem to change. Might be related to my usage of nightly builds.. —TheDJ (talk • contribs) 21:20, 13 May 2009 (UTC)

I was just doing a bit more checking... Safari 3.2.2/WinXP shows the first two as the same size, but IE8 does show all three as different sizes. Didn't someone make a font size charr for checking this a while back? ---— Gadget850 (Ed) ^talk 11:25, 13 May 2009 (UTC)

Opera 9.51 shows the first two as the same size as well. ---— Gadget850 (Ed) ^talk 11:29, 13 May 2009 (UTC)

Yeah, that was me: User:Edokter/fonttest. 90% takes less space in IE because only numbers are reduced in size, and capitals are slightly less high, but the letters have the same size/spacing. If you look at the screenshots, you will notice that in most non-IE cases, 88% and 90% are the same. — Edokter • Talk • 12:24, 13 May 2009 (UTC)

Still, no one has explained why you want to reduce the text size in the first place? If there is no good reason and it makes part of the page less accessible, then it seems like a really bad idea? Again: Why not bring the text size in FF back up to IE size instead? I'd prefer accessible to more people when it's possible?
—Apis (talk) 14:45, 13 May 2009 (UTC)

If that is what you want to do, just edit {{Reflist}} and remove "references-small" there. —TheDJ (talk • contribs) 14:53, 13 May 2009 (UTC)

Thats a good suggestion, but it's not what's being discussed here. .references-small is being used in more places. If we want to normalize text-size why should we pick the size used in FF as the target and not IE? Most people are used to the larger font-size? Every time text-size is reduced, someone comes here and complains afterwards because it gets harder for them to read, why shouldn't we respect that? What's the point in small text? It's not like we need to save ink or paper?
—Apis (talk) 15:19, 13 May 2009 (UTC)

To clarify: what is being suggested is reducing the text-size in .references-small for all IE users... right?
—Apis (talk) 15:25, 13 May 2009 (UTC)

What's being discussed is aiming for the font-size being the same between any browser. I picked IE because it seems the only browser that differs in rendering. We could indeed bring other browser up to how IE renders it, but that would generate an equal ammount of 'complaints'. I also believe it is not the size (many ohter elements use that font-size), but the change that casuses the complaints. — Edokter • Talk • 15:34, 13 May 2009 (UTC)

It's great if the all browsers render the page similarly, I just question why we have to choose the smaller text, when what most wikipedians see today is the larger IE version and not the FF version. I really don't think those who complain about small text simply "don't like change" as you say. I know a lot of people that find it hard to read on computer screens and Internet pages, often because the text is too small.
—Apis (talk) 22:04, 13 May 2009 (UTC)

It is not a question which browser is used the most, but how the pages are intended to look like. Most CSS 'hackers' actually do not use IE; instead, they tend to test changes in many browsers as possible (including IE I hope). I proposed to make the font smaller, because that is what I believe it is supposed to look like. — Edokter • Talk • 23:46, 13 May 2009 (UTC)

I agree with Edokter— we are discussing how to best fix a technical problem in that .references-small does not work as intended. Where and how it should be implemented should best be discussed on the VP. I advise you to take a look at the VP and {{reflist}} archives on previous discussion. ---— Gadget850 (Ed) ^talk 18:23, 13 May 2009 (UTC)

We going anywhere on this or should we advertise on the VP? ---— Gadget850 (Ed) ^talk 01:07, 29 May 2009 (UTC)

On a related note

There are some font-size:100% for NavFrame etc as well. —TheDJ (talk • contribs) 21:08, 12 May 2009 (UTC)

I need to check if those override earlier font-size declarations. They probably don't, but better safe then sorry. — Edokter • Talk • 23:05, 12 May 2009 (UTC)

HiddenStructure and Prettytable

I think that is no need to keep these two CSS classes (hiddenStructure and Prettytable). HiddenStructure is not used anymore, thoung it has been kept for compatibility with old templates I think there isn't anything (template, article, etc..) using it anymore. Prettytable has the same purpose that "wikitable" but it is not widely used, so why should we keep the bot classes doing the same thing?, erasing this will standarize a little further the wikipedia code. Locos ~ epraix Beaste~praix 18:47, 1 June 2009 (UTC)

The code in Common.css is not to implement hiddenStructure, but to break it, so it doesn't function properly and there is no incentive to use it. We will need to keep the declaration here until it is removed from the main wiki stylesheets (T19009). Prettytable is used in a few hundred pages (although many fewer than the last time I looked, has someone been doing a clearout?); I agree it should be deprecated, replaced in the wild by wikitable, and then removed, but the process has to happen in that order. Happy‑melon 18:56, 1 June 2009 (UTC)

Is there any way to know which pages are using a determined CSS class? Locos ~ epraix Beaste~praix 23:48, 5 June 2009 (UTC)

coord templates

Has anyone else noticed that in the last week or two - the coordinates templates is displaying the coordinates in such a way that they are pierced in the center by the horizontal line underscoring the article title. Rather than being above it. I couldn't find the class that is used to display the coordinates in the {{coord}} or {{coord/display/title}} templates but maybe somebody here knows how these work. BTW - I am using Chrome and the coord template was not exhibiting this behavior in May (for sure) and maybe a later - dont' know exactly when it changed. --Trödel 06:00, 16 June 2009 (UTC)

blue box behind the tabs

Does anyone else notice there is a light blue box behind the tabs at the top of each page? —Ruud 20:02, 16 June 2009 (UTC)

Styling tags

Now that Tim's finally scapped above r52071, tags are now wrapped in an identifying span so we can style them as desired. The question is, do we want to style them? If so, how? My personal favourite is for something like this:

08:55 Cobra Group (company)‎ (diff; hist) . . (-188) . . 79.121.174.249 (talk | block) (→ Companies associated with The Cobra Group: They are not clients and they are not mentioned in the url ref. to) [rollback] (references removed)

That is, small, bold and italic. Alternatively, recolouring them (dark red?) might be viable, or a suitably subtle background. Thoughts? Happy‑melon 09:50, 18 June 2009 (UTC)

Yuck to the idea of a background. Personally, I like the one you've shown here - though keep in mind that at that font size, bold has virtually no effect except to make it a little harder to read. I'd suggest just going with small and italic. Ale_Jrb^talk 11:32, 18 June 2009 (UTC)

I'd prefer a little bigger if possible. Cenarium (talk) 22:15, 23 June 2009 (UTC)

How is it now? Ruslik_Zero

I added the following code:

.mw-tag-marker {
 font-style:italic;
 font-size:90%;
 font-weight:bold;
}

Ruslik_Zero 19:20, 25 June 2009 (UTC)

I like the way it is now. Cenarium (talk) 20:22, 28 June 2009 (UTC)

Use tabs instead of spaces

Hi!!

Is it possible to use the tab character

"	"

instead of spaces for reducing the size of the style sheets? Helder (talk) 15:46, 24 June 2009 (UTC)

It is possible, yes, but it wouldn't really help that much. If we'd go that way, it would be more effective to just drop the comments (and put them on a documentation page) and all indentation. In the end, CSS pages are cached long enough for this consideration to be not particularly important. (Also, I don't like tabs.) —Ms2ger (talk) 16:31, 24 June 2009 (UTC)

I second the idea to move comments elsewhere (how useful e.g. is padding: 0.25em 0.5em; /* 0.5em left/right */ ?). As for caching, as far as I know many browsers reload CSS/JS on each visit, and quite many peeople make short visits to Wikipedia, so imho the size is still important. — AlexSm 16:42, 24 June 2009 (UTC)

Note that dropping comments and removing newlines can affect how CSS and JS behave. Some slightly broken browsers will parse CSS selectors differently if they contain comments, eg foo, /*,bar*/,baz {}. The minified CSS/JS is not the same as the original, and this must be taken into account. --Splarka (rant) 08:52, 26 June 2009 (UTC)

Isn't this stylesheet send gzip'd? In that case using tabs would save little to no bandwidth. —Ruud 17:17, 24 June 2009 (UTC)

Sadly, gzip isn't perfect. Removing tabs and spaces does indeed affect the size, though removing comments as well would be much better. And with TCP/IP, even a little change can make a noticeable difference. Consider what happens when your saving of 100 bytes eliminates the need for the client to send an ACK before the file was fully transferred. If the round trip time is 80ms, you just saved that much. Sometimes even the uncompressed size can matter; the iPhone famously only caches objects that are 25kb or smaller uncompressed, affecting both Monobook's main.css and wikibits.js. Wikipedia gets over 300 million hits a day. It's time we started acting like it and concentrating on front-end performance like other major websites. Minifying both generated and static .js and .css files but adding a preference allowing script and style debuggers to disable this would be a good start. It's not hard (especially for the static case, just run something like YUICompressor over the files) and it can make a real difference, especially for the very people who Wikipedia is most intended to serve - those in developing countries with limited bandwidth and computing resources. GreenReaper (talk) 13:07, 25 June 2009 (UTC)

Before gzip converting consecutive spaces to tabs saves ~1700 bytes (~7.0%). After gzip it saves about 37 bytes (~0.5%). (Testing on the current Common.css with compression level 9 and run in Python, not sure exactly how gzip for web is actually configured.) Dragons flight (talk) 18:07, 25 June 2009 (UTC)

That sounds about right. You can probably gain a little more by converting uppercase variables to lowercase (yep, really - uppercase is less common and so compresses less well), or removing trailing semicolons. But you gain a lot more (literally up to 50%) by getting rid of the comments, because those are as complex as the code itself, if not moreso. GreenReaper (talk) 18:27, 25 June 2009 (UTC)

Removing comments reduces size by 7500 bytes (30%) before compression and 3000 bytes (44%) after compression. I would say though that having a code cleaner in Mediawiki is a much better idea than asking Wikipedians to work with uncommented files. Dragons flight (talk) 18:45, 25 June 2009 (UTC)

Spaces are universally supported by all browsers and are easy to type. Tabs can cause problems and usually require copying and pasting. They also usually lead to inconsistency when the page is updated later. Apologies, but I don't view the think of the children in Africa line of thought too favorably. --MZMcBride (talk) 17:50, 25 June 2009 (UTC)

In the end, isn't a case of Wikipedia:Don't worry about performance? I'm sure if this really is a problem, the developers could solve it much more efficiently and effectivly by doing something on the server-side (like the above mentioned YUICompressor, or slimming down the HTML of the actual articles instead of just the stylesheet). Actually I think Brion wrote a blog entry about this a few moths ago. On the otherhand, I've seen repeated mentions of Wikipedia doing very badly on page render-time and script execution ([1] [2]), so it might be worth investigating to what extent the scripts at MediaWiki:Common.js contribute to this. —Ruud 18:26, 25 June 2009 (UTC)

The blog entry in question states:

make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request

I specifically asked brion what he meant by "compressed" there, his reply was [21:33:24] <brion> gzip. This has been done, the skins folders now serve gzipped files. It was not about minification (what he calls "obfuscation"). If jQuery is to be integrated, it will come pre-minified, but that is an external (and somewhat static) library, not a large pile of rapidly changing, highly buggy CSS and JS. Both Tim and Brion in the recent past have objected to obfuscation of these, and that was before WMF served it all gzipped. --Splarka (rant) 08:52, 26 June 2009 (UTC)

I agree this is ultimately a developer issue. I'm looking to improve things from that end myself. However, there are issues that impinge on editors. For example, would it be acceptable to minify CSS and javascript on a site and user basis, if a preference was available to turn off that minification for a particular user? There are also performance considerations in the use of certain CSS rules and Javascript functions (tools like Firebug with Page Speed can help here). This is not something that developers have historically spent a lot of time on compared to server performance, but it can have an impact on the end-user experience - and it is also modifiable by editors. GreenReaper (talk) 18:37, 25 June 2009 (UTC)

Thanks for all the links and explanations above! =) I'm learning a lot with it! I have some questions:

Is there any coding convention being used to edit the css and js pages at Wikimedia projects? Any recomendation? (I'm an collaborator of pt.wikibooks)
Is it possible to change the behavior of the "tab key" at css and js pages in order to get "N spaces" or even the "tab character" instead of jumping to the Summary field? (maybe using javascript?)
What about remove all the comments from the pages that are loaded for all users and to use a separated page for maintain a "commented version" of them?
- Another possibility (not a nice one): We could use the same page and alternate editions: one with the comments and the following without comments and indentation. Then, if someone needs to edit the code, he should go to the previous edit of the page, make the changes and save. Then he should use some automated tool (maybe a new gadget) to save an minified version of the page with the result of some automated tool to remove spaces and comments... This way, the page will be always in its minimum size, and the comments can be found using the history page.

By the way, considering that these pages have a different purpose than other wikipages, it would be interesting to have some features of "code editors" in it. Helder (talk) 22:48, 25 June 2009 (UTC)

Tabs are evil incarnate ;) please don't use them (or trailing whitespace). This is, of course, a long-running debate. Just use a single space to indent and the question is largely moot. Also, move those K&R-style '{' characters down onto their own line. Be quite careful cutting comments as some are part of standard hack techniques. (and I don't favor aggressive support of lame browsers). Cheers, Jack Merridew 09:09, 26 June 2009 (UTC)

Problem solved

Okay, so not exactly, but I wrote an extension to bundle the YUI CSS compressor and the JSMin Javascript compressor into a single utility that would automatically contract all the CSS and Javascript files generated by Mediawiki. It will need to be reviewed to make sure it works appropriately on Wikimedia sites before being considered for installation here, but assuming that it (or something like it) is ultimately installed then all this worry about formatting and comments could be ignored. Dragons flight (talk) 07:36, 26 June 2009 (UTC)

bugzilla:12250#6:

This feature request though was about *obfuscation* for the purposes of making
the files smaller; that's something we'll reject regardless of the use or
non-use of gzip compression, as it makes debugging and customization much more
difficult.

--Splarka (rant) 08:10, 26 June 2009 (UTC)

File	Bytes Raw	Bytes Minify	Ratio	Gzip Raw	Gzip + Minify	Ratio
MediaWiki:Common.css	24609	13340	54.2%	6975	3513	50.4%
MediaWiki:Print.css	1485	456	30.7%	748	247	33.0%
MediaWiki:Handheld.css	403	331	82.1%	176	144	81.8%
MediaWiki:Monobook.css	5447	2814	51.7%	2128	1064	50.0%
index.php?title=-&action=raw&maxage=2678400&gen=css	75	34	45.3%	92	51	55.4%
index.php?title=-&action=raw&gen=js&useskin=monobook	29664	18951	63.9%	7844	5352	68.2%

Using gzencode level 9.

Assuming every new visitor gets Mediawiki:Common.css + MediaWiki:Monobook.css + gen=css + gen=js:

Gzip = 17039
Gzip + Minify = 9980

Savings of 7059 bytes per visitor, ~1.5 seconds for a user on dialup, and about 800 GB of bandwidth savings per day (given Erik Zachte's numbers showing 500,000,000 action=raw hits per day), which would reduce WMF's total bandwidth by ~1.8%.

Whether that is worthwhile or not is someone else's problem but it certainly seems like it could be. Dragons flight (talk) 09:09, 26 June 2009 (UTC)

Hey Dragons flight, you are fast! =)

When is said that "it makes debugging and customization much more difficult", I should point that debugging is of interest just a few of the wikipedia users (the reader are not interested in look at the css or js of the pages they are reading). So, the extension could be used and an option to disable it should be added in somewhere at the Preferences. This option should be set by the admins and other interested in debugging css of the pages. This seems good to the two sides, since the debuggers can see the commented css (checking the new option at preferences) and the readers get a light page (with the minified version on the css and js). What do you think? Helder (talk) 00:02, 28 June 2009 (UTC)

By the way, with this extension the css/js is minified on each view of each page? Or this is made only when a new version of the css/js page is saved, and the extension saves the minified version at this point? Helder (talk) 00:05, 28 June 2009 (UTC)

Combine rules

div.NavFrame p {
    font-size: 100%;
}
div.NavFrame div.NavContent {
    font-size: 100%;
}
div.NavFrame div.NavContent p {
    font-size: 100%;
}

Any reason why these aren't combined? --- RockMFR 15:48, 26 June 2009 (UTC)

They could be removed, as 100% has no effect unless they override previous font-size declarations. (edit) That seems to be the case, so yes, they can be combined. — Edokter • Talk • 14:22, 27 June 2009 (UTC)

Removing prettytable and wikitable

If someone could (maybe by searching a dump) replace all occurences of class="prettytable" with identical class wikitable (already discussed above at #HiddenStructure and Prettytable), then both classes can be removed from Common.css due to rev:48842 (or moved to Simple.css since "simple" skin doesn't seem to call shared.css). — AlexSm 21:14, 26 June 2009 (UTC)

An effort is being made to make these replacements in a wide number of articles, which is admittedly slow-going, although I don't personally know how to search a dump, or what that is. Wildhartlivie (talk) 22:08, 26 June 2009 (UTC)

The wikitable code has been deployed in shared.css for a while now btw. Do we have any idea what the progress is with the remaining prettytables ? —TheDJ (talk • contribs) 02:12, 12 August 2009 (UTC)

reference:target

Could someone please add...

/* Highlight clicked reference in blue to help navigation */

ol.references > li:target,

sup.reference:target, span.reference:target,

cite:target {

background-color: #DEF;

}

This is to allow the citation templates to use <span> instead of <cite>. As discussed here, the present use of <cite> is incompatible with its definition in HTML 5. -- Fullstop (talk) 10:58, 10 August 2009 (UTC)

Hmm, ok, but this likely will also effect: "cite *.printonly" and MediaWiki:Print.css "#content cite a.external.text:after". And all this will need a 30 day staging period before we are sure all browsers will have the new CSS. —TheDJ (talk • contribs) 11:10, 10 August 2009 (UTC)

Oh, right. So, similarly,...

A) cite, span.reference {

B) cite *.printonly, span.reference > span.printonly {

I wouldn't bother with a change of MediaWiki:Print.css. The citation templates could use the nourlexpansion class. -- Fullstop (talk) 11:28, 10 August 2009 (UTC)

ps: (somewhat off-topic) Just a thought: Is there some reason why .printonly has to be limited to <cite>? Seems like .printonly could be generic, just as .noprint is. -- Fullstop (talk) 11:50, 10 August 2009 (UTC)

The child operator > won't work with IE-old, is that a problem? I agree there doesn't seem to be much reason to limit it to particular parent element types. (also)Happy‑melon 19:18, 10 August 2009 (UTC)

If .printonly were limited, the failure of IE-old to recognize '>' would result in "Retrieved from http://..." (normally only visible in print) being visible on screen. Ugly, but not life threatening. :) -- Fullstop (talk) 21:42, 10 August 2009 (UTC)

P.S. On one page you talk about using the class "reference", and on the other about using "citation". I think it's one or the other :D —TheDJ (talk • contribs) 22:12, 10 August 2009 (UTC)

Also, there is a large difference between printonly and nourlexpansion. What references used to have, was the url twice. The first inclusion a named link. Named link are normally expanded (raw url is automatically added in print, unless the class nourlexpansion is used), but in references they were not expanded. Instead the link was included a 2nd time, this time hidden normally, but shown in print (printonly). The reason for this was to support older browsers which cannot handle the "after" CSS selector. I'm not entirely sure how it work at the moment, but I'm not 100% sure if all these changes properly account for this. —TheDJ (talk • contribs) 22:18, 10 August 2009 (UTC)

The changes I'd make are

Old

New

ol.references > li:target,
sup.reference:target,
cite:target { 
    background-color: #DEF;
}

ol.references > li:target,
sup.reference:target,
span.citation:target, cite:target { 
    background-color: #DEF;
}

cite {
    font-style: normal;
    word-wrap: break-word;
}

span.citation, cite {
    font-style: normal;
    word-wrap: break-word;
}

@media screen, handheld, projection {
    cite *.printonly {
        display: none;
    }
}

@media screen, handheld, projection {
    span.citation *.printonly, cite *.printonly {
        display: none;
    }
}

No need to change MediaWiki:Print.css, thanks to User:Fullstop's edit. I'm using the citation class, to avoid clashes with sup.reference. Is any admin still doing editprotected requests at the moment? —Ms2ger (talk) 09:57, 11 August 2009 (UTC)

Done, please remember the 30 day staging period. —TheDJ (talk • contribs) 11:24, 11 August 2009 (UTC)

Thanks, I will. —Ms2ger (talk) 12:17, 11 August 2009 (UTC)

Thanks. -- Fullstop (talk) 13:56, 11 August 2009 (UTC)

They should not be including the URL in the displayed HTML. MonoBook use to do this as a workaround for IE until somebody used the onbeforeprint events. Its a problem for non-css browsers (like lynx and Dillo) as the output text to become nearly unreadable. — Dispenser 01:46, 12 August 2009 (UTC)

Fundraiser Classes

en.wikipedia.org#table(class=fundraiser-box)
en.wikipedia.org#span(class=fundquote)

I was not able to find either of these classes. Does anyone know where they are? Or I am looking in the wrong place as well. --166.70.99.89 (talk) 06:27, 11 August 2009 (UTC)

Does no one remember the wiki-ad campaign (maybe one or two years ago)? I think these were the classes used for the templates (of course). Does anyone know where they are now? I want to make the ads on my website look better and want to use those classes to improve it. --166.70.99.89 (talk) 06:35, 11 August 2009 (UTC)

donate banner (whatever one wants to call it). Does anyone know where the classes (listed above) for that are possibly? --166.70.99.89 (talk) 06:42, 11 August 2009 (UTC)

I took a look in Special:System messages and could not find it there. Or, does anyone know, does the entire donate banner just use MW's message thing? --166.70.99.89 (talk) 20:19, 11 August 2009 (UTC)

It was a centralnotice. No specific code was listed here and i have no idea where it IS hosted. —TheDJ (talk • contribs) 20:38, 11 August 2009 (UTC)

It seems to be coordinated at meta:CentralNotice. Don't ask me where the actual notice is, though (a somewhat-targeted search really doesn't help much, unless someone wants to sift through 10,000+ results). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:45, 11 August 2009 (UTC)

Not trying to sound rude or anything however that cannot be the case. Remember about 2 years ago (maybe a bit earlier) where people added fake pro-wikipedia and pro-editing wikipedia ads (banners, whatever) onto their userpages? The general layout and MW implementation is what I am looking for so I can manipulate the ads I added to my site without having to use backend code. I think the class "fundraiser-box" probably has that information in it; however I cannot find the damn thing. Also, do you mean wikipedia (when doing a end-of-the-year fundraiser) only uses the backend system message tool or do they use the "fundraiser-box" and implement it into a .css file for the time? --166.70.99.89 (talk) 21:32, 11 August 2009 (UTC)

Wikitable borders disappear in email, blogs, disks, mobile devices

New wikitables no longer show up in email, blogs, disks, mobile devices, etc..

From MediaWiki talk:Common.css/Archive 5#Wikitable borders without CSS:

"The reason to add border="1" is mainly the reason number 1 I stated above: To make our tables readable even when people copy and send Wikipedia pages through email or store them on disk as plain HTML or view them over lightweight interfaces for mobile devices and other such situations where the CSS code doesn't come with the page. There is no other way to achieve that. And adding the border="1" doesn't affect how the table looks on Wikipedia, so it has no negative effects."

Below is the current table produced by clicking the table button in the edit window toolbar:

---

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

---

Paste it into your email or Wordpress blog to see what I mean. It produces something like this:

header 1 	header 2 	header 3
row 1, cell 1 	row 1, cell 2 	row 1, cell 3
row 2, cell 1 	row 2, cell 2 	row 2, cell 3

The borders are gone.

Wikitable CSS (class="wikitable") should not be the sole basis for borders. Table borders are essential, just like paragraph tags (<p>) and line breaks (<br>).

ca-delete !important

Why is the #ca-delete rule marked as !important? This is not necessary, as far as I can see. --- RockMFR 23:22, 13 August 2009 (UTC)

Printing out dates of old article versions: needed back

If I print out an article from its history, the pink banner which is visible on screen ("This is an old version of the page, as edited by xxx on xxx etc etc") does not print out (I've tried several pages). I'm sure it used to. Is this a deliberate change? If so, why? I found the printed banner just as useful as the one on screen.

Thanks for any info and help

89.48.77.8 (talk) 05:53, 19 August 2009 (UTC)

Shows up on "Printable Version" for me, and I don't see any recent edits to MediaWiki:Revision-info, MediaWiki:Revision-info-current, or MediaWiki:Print.css that would cause it. Odd. --Splarka (rant) 07:38, 19 August 2009 (UTC)

Oops, it is hidden. It is because of #contentSub ... {display: none;} on MediaWiki:Print.css added here. --Splarka (rant) 07:49, 19 August 2009 (UTC)

It is pertinent to have the date printed, back, I mean printed on the bottom of the printable version. This serves a minimum of "priority date" (publication date) e.g. for legal purposes where users like offical organisations save a printed or PDF-printed version in their repositories as prior art. Please can the persons in charge of this restore the #contentSub value for print.css so that the date is printed ? --Wikinaut (talk) 09:14, 20 August 2009 (UTC)

I have presented a solution at your original post on the Village Pump. ---— Gadget850 (Ed) ^talk 09:57, 20 August 2009 (UTC)

I've removed the relevant code from Print.css until we get a better solution. It's better to show stuff that we want hidden rather than to hide stuff that we do want shown (in my opinion). — RockMFR 21:09, 23 August 2009 (UTC)

Free pdf readers

Adobe icon is not free, AFAIK, and to use it make people feel that only Adobe proprietary software can be used to open PDF files, and that's far from truth: see PDFreaders FSFE initiative. Maybe we could use this graphics (e.g. the last one), instead. --Nemo 17:41, 28 August 2009 (UTC)

We could, but I don't think we should. The icon is supposed to ADD information, a green unfamiliar icon will just confuse people. I vote we remove the pdf icon and replace it with a generic document icon. —TheDJ (talk • contribs) 18:01, 28 August 2009 (UTC)

I guess TheDJ is right, a new icon will only confuse readers. I agree with his proposal. --Locos epraix ~ Beastepraix 18:21, 28 August 2009 (UTC)

bugzilla:20428 —TheDJ (talk • contribs) 18:22, 28 August 2009 (UTC)

The icon does add information, since there's a clear "PDF" writing and a link to a place where you can download a free pdf reader (current icon doesn't do so). Or, we could use another icon (e.g. the one suggested by tpascal), and still link to that website. --Nemo 18:51, 28 August 2009 (UTC)

At 14px, the PDF is illegible. like on the current icon, but at least that is an icon that everyone recognizes. And we can't use the image to link anywhere, because it is pure CSS. —TheDJ (talk • contribs) 19:30, 28 August 2009 (UTC)

Why do we need a bugzilla case on this? The PDF icon is on Commons at File:Icons-mini-file acrobat.gif and is sourced from FamFamFam. If the image is really not free, then we upload a free image over top of the old. ---— Gadget850 (Ed) ^talk 20:51, 28 August 2009 (UTC)

Yes, that is the image. However, the image automatically applied to PDF links by mediawiki is hard coded into the software and changes to a file on commons won't affect it. Ale_Jrb^talk 21:04, 28 August 2009 (UTC)

Also note that it doesn't matter who made that actual icon, it contains the Adobe reader logo, which obviously has (many) rights reserved . Ale_Jrb^talk 21:08, 28 August 2009 (UTC)

I guess I'm missing something, as it appears to me the image is linked in the CSS as "http://upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif". If the image is non-free, then it should not be on Commons. If I am right about the location, then the simplest solution is to find a free image an upload over the non-free version, thus updating every use. ---— Gadget850 (Ed) ^talk 22:03, 28 August 2009 (UTC)

I've nominated the image for deletion. If the image is deleted, we could possibly use File:Icon pdf.gif. — RockMFR 23:09, 28 August 2009 (UTC)

Standard background colors

Many tables on Wikipedia contain repetitive, scalar kinds of information. Some people made templates for this task such as {{yes}} which usually transclude a cell background color and a default text. These are widely used as far as I can see. I’d like to pose the question whether the colors and sets shouldn’t be standardized more and then moved to MediaWiki:Common.css as much as possible. Please see the collective Talk page. — Christoph Päper 13:07, 15 September 2009 (UTC)

Remove mw-plusminus-pos

Please remove the following per rev:53289, now live in shared.css. — AlexSm 04:17, 18 September 2009 (UTC)

/* Coloured watchlist numbers */
.mw-plusminus-pos { color: #006400; } /* dark green */
.mw-plusminus-neg { color: #8B0000; } /* dark red */

Done by RockMFR. Locos epraix ~ Beastepraix 15:43, 19 September 2009 (UTC)

Add class for style examples

Could you please add .example { font-family: 'Georgia', serif; color: #006F00; }? The class example is used by {{xt}} which uses it for examples of styles, like this. (It is widely used on WP:MOS and some of its sub-pages.) Now the styling is specified in the template itself, but moving it here would save a few bytes each time the template is used, and would allow users to customize its style. (There is also {{!xt}} using the class bad_example and the style font-family: Georgia, serif; color: #B20000; like this, but it is an experimental template which isn't used yet.) --___A. di M. 21:15, 12 October 2009 (UTC)

See Wikipedia talk:Manual of Style#Green text. ___A. di M. 21:17, 12 October 2009 (UTC)

No need for sitewide CSS. Add the class to the template, and users can customise it using the !important keyword. Yes, it would save a few bytes on WP:MOS, but by adding the same bytes to the other 60,577,279 pages. Happy‑melon 21:49, 12 October 2009 (UTC)

Here are the detailed instructions how to use the !important keyword: Wikipedia:Catalogue of CSS classes#CSS caching is !important

--David Göthberg (talk) 13:11, 23 October 2009 (UTC)

Rendering of donation message with Opera 9.64 and Opera 10

I do not know where to post this message. I hope someone can send it to the right place. Thanks! :-)

Please have a look at the rendering with Opera 9.64 and Opera 10. The "donate by credit card" and "donate via paypal" buttons are very hard to read as you can see. I have no screenshot of the top-banner because it is not displayed anymore, but it was about the same, and was also hard to read. I hope someone can fix this issue. Yours, Dodoïste (talk) 23:40, 11 November 2009 (UTC)

Feedback on that should go here: [3]. Rd232 ^talk 01:33, 12 November 2009 (UTC)

Done, thank you Rd232. :-) Dodoïste (talk) 11:05, 12 November 2009 (UTC)

Removal of donation messages

The Wikipedia Signpost has related articles:

“Wikipedia Forever” fundraiser arouses controversy

There is a strong consensus on the Village Pump to remove the donation banners until they are "fixed." The CSS addition to remove the banners is:

div.notice-all {display:none !important;}

Thoughts? Brandon (talk) 08:04, 11 November 2009 (UTC)

Strong Support, the banner is just embarrassing, the sooner someone takes the plunge and gets rid of it the better. Lankiveil ^{(speak to me)} 08:25, 11 November 2009 (UTC).
Strong support for removing the banner. Wikipedia is childish in many respects, but this banner even more so. Wikipedia doesn't deserve this. Hans Adler 08:28, 11 November 2009 (UTC)
I've never seen such a strong consensus anywhere on Wikipedia. As it appears that the concerns are not even being taken in consideration, this proposal has my tentative support. — Martin (MSGJ · talk) 08:30, 11 November 2009 (UTC)
Support. Too big, too childish, not clear enough in meaning (sounds like a slogan/motto, not an invitation to donate). Just awful. Hide until it is changed to something acceptable. Rd232 ^talk 08:47, 11 November 2009 (UTC)
Support Vivé la revolución! </tongue in="cheek"> The Twitters make me change my tune; I'll leave it to the Marketing department to sort out. --Cybercobra (talk) 11:15, 11 November 2009 (UTC)
Support This banner has been a bad idea from the start. Remove move it now before its too late. Seddon ^talk|^WikimediaUK 09:19, 11 November 2009 (UTC)
Support Incredibly obnoxious and looks like a /b/ attack. -Jeremy ^{(v^_^v Stop... at a WHAMMY!!)} 09:22, 11 November 2009 (UTC)
Support, because, damn.—S Marshall ^Talk/_Cont 09:43, 11 November 2009 (UTC)
Exterminate. MER-C 09:57, 11 November 2009 (UTC)
Let it burn!. 189.105.13.116 (talk) 10:16, 11 November 2009 (UTC)
Strong Support They are awful, embarrassing and unprofessional. Paul August ☎ 16:21, 11 November 2009 (UTC)

Given the volume of opposition here (including VPR) and Meta ([4]), I suggest taking stock at 12.00 UTC and hiding it then if no substantial opposition to hiding emerges. Then there'll be the question of "what happens next". Rd232 ^talk 09:32, 11 November 2009 (UTC)

Hiding it would arguably go beyond our remit, and so I would suggest a last-ditch attempt to discuss the issue with the WMF before we take such a drastic step. They need to raise money, that is clear. However the editors here are just as important to the success of Wikipedia and they can not and must not use advertising techniques which we find so amateur and inappropriate. We need dialogue, but this proposal remains viable as a last resort. — Martin (MSGJ · talk) 09:57, 11 November 2009 (UTC)

Discuss how? What would be the contact route? And who's going to do that? Rd232 ^talk 10:12, 11 November 2009 (UTC)

Cary Bass would be that person. Seddon ^talk|^WikimediaUK 10:25, 11 November 2009 (UTC)

On the other hand, this is supposed to be a ten-week-long campaign (cf. m:Fundraising 2009/Timeline). I'm not sure delaying a week in order for better banners to be made is an unreasonable thing to do. --MZMcBride (talk) 10:00, 11 November 2009 (UTC)

Absolutely. This is an annual fundraising drive, a delay of a week to improve it when it's this wrong is entirely justifiable. Rd232 ^talk 10:10, 11 November 2009 (UTC)

Heck, they can extend it for a week at the end to make up for a lost week now, its no trouble at all. These banners need to go, theyre tarnishing Wikipedias reputation. 189.105.13.116 (talk) 10:16, 11 November 2009 (UTC)

Yes, by all that is good in this world, remove those banners and go back to the drawing board! It's not a problem of having banners, and no one is saying that having banners is evil here. We all want the fundraising campaign to work. What we don't want is our image to be a bunch of juvenile kids with delusion of grandeur running for class president. Wikipedia Forever? Back to the drawing board.

The Wikipedia model has always been based on consensus and involving the community. I understand that some people will always oppose the banners no matter what, but you should at least be able to garner consensus from those who want to help. How hard would it have been to have asked "The fundraising campaign starts on X day, calling upon volunteers to send their ideas for banners". See which banners have support, see those that haven't, and then the WMF can make its pick amongst a bunch. It certainly wouldn't have cost 250K$ for these designs. What a damned waste of money.

In a nutshelf you shot yourself in the foot. Disable the banners, give us a week to come up with something sane, and then re-enable them. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 13:35, 11 November 2009 (UTC)

Hello all,

our decisions which banners to run are primarily based on performance. So far, "Wikipedia Forever" appears to be performing on about the same level as other banners which we ran last year, but we'll run the full metrics soon. In any event, donor response is almost always completely separate from community response; community members hating a banner tells us very little about how well it works or how the general public perceives it. (That doesn't mean that anything which performs well is acceptable from our point of view, of course.)

We'll observe community feedback, as well as feedback from the general public and our donor community. This isn't the only banner we'll run this year - most importantly, we'll run another personal appeal from Jimmy, which performed at about 10 times as well as any other banner last year. As always, removal of the site-wide fundraising messages by community members isn't OK; please be patient and click the "hide" link or remove the banner through your personal user style if you really despise it.--Eloquence * 10:30, 11 November 2009 (UTC)

By the way, if you want to help us create mock-ups for alternative banners, as every year, you're more than welcome; I've created m:Fundraising 2009/Alternative banners as a central space for doing so.--Eloquence * 10:30, 11 November 2009 (UTC)

Ignoring the hundreds of complaints isnt ok either, I will fully support any administrator who removes it on any project. I donated last year but I'm not doanting again untill this thing is gone. If its performing on about the same level as the other banners then why not use the other ones? We're paying a PR firm to developed something that has not increased performance over previous years and is making Wikipedia look very very bad. Tha banner gives a completely wrong idea about who we are and what we are doing, it needs to go.! Acer (talk) 10:36, 11 November 2009 (UTC)

As I said, we'll have detailed comparison metrics soon, and will make our decisions based on that. Please be patient. Can you clarify how the current banner gives a "completely wrong idea about who we are and what we are doing"? Do you feel that is true for the donation landing page as well, or only for the banner?--Eloquence * 10:40, 11 November 2009 (UTC)

Erik, quite simply, you're missing the entire point. No graph or metric in the world is going to make these banners acceptable to the community. It's not the banner performance that's the issue here, it's the fact that people's hard (volunteer) work is being placed under such a banner. You really would do well to read the comments here: Wikipedia:Village pump (proposals)#Abolish the silly headers. If you read the community's comments and still can't figure out what the issue is, then there's really no further need for you to post here. --MZMcBride (talk) 10:44, 11 November 2009 (UTC)

You're an admin, Erik - you can respect the community's views on this and turn off the message until it can be replaced with something that performs equally well but isn't ludicrous. Or if you have other messages ready to go, just ditch it now, replacing with another. Rd232 ^talk 10:49, 11 November 2009 (UTC)

As I said, please be patient so we actually have the full data relative to last year. If you click Special:Preferences and "Gadgets", there's a little option "Suppress fundraising banner" that you can use if you find it too annoying to wait.

I'm watching Twitter comments as well. I see a lot of comments from Wikipedians hating the banner, but I also see the first comments from donors and the public, including positive ones: [5] [6] [7] [8]. It's important to recognize that the Wikipedia community has a default sensitivity against anything intruding into the everyday experience of Wikipedia. Every single fundraising banner we've ever run has provoked varying levels of outrage, including threats to disable the banner for everyone, demands to go back to the drawing board, etc.

So we have to operate on the assumption that any banner that works is going to offend people inside the community, because that's held true for every banner we've ever run. That makes it difficult to distinguish "normal" unhappiness with fundraising messages from extraordinary unhappiness. It's also true that the kick-off of the fundraiser is always the loudest time, and we've decided to kick things off with an unquestionably loud/bold banner. So I'm not surprised that there's a particularly strong reaction, and can only reiterate my call for patience. More specific feedback also helps: there's clearly a strong aesthetic component (I'm not particularly fond of all-caps myself and have asked to ensure we try regular case banners as well), but also a messaging component. The messaging this year is focused on preserving and protecting Wikipedia for future generations: do you feel that message conflicts with your view of Wikipedia, and if so, why?--Eloquence * 11:04, 11 November 2009 (UTC)

Three of those four are just echoing the slogan. That's a positive message? Rd232 ^talk 11:09, 11 November 2009 (UTC)

I'm left wondering: if you discovered that all of those Twitter users were also Wikipedia editors, would you be completely discounting their voices as well? --MZMcBride (talk) 11:13, 11 November 2009 (UTC)

I'm not discounting comments, I simply think we need to find a balance between the direct interests of Wikipedians (to have a clean site experience) and the indirect interests of Wikipedians (to have a site), and doing so takes time and a bit of patience. I am, however, saying that the reaction of Wikipedians is always, always significantly different from the reaction of the general public. That only makes sense, and is important to not forget. If we tried to arrive at a fundraising message that the most people on Wikipedia agree with, we'd probably have a plain text "Donate to Wikipedia" link at the top raising a percent of what we need.--Eloquence * 11:25, 11 November 2009 (UTC)

THAT NICE ELOQUENCE SO GOOD YOU NO VERB NON STANDARD ENGLISH US SPECIFIC ENGLISH BREAK CSS WIKIPEDIA LOGO OTHER PROJECTS OVER SPACE MOST CAMPAIGN DEMEANING ARROGANT SLOGAN CLEARLY MONOCULTURAL SLOGAN FOREVER FIFELFOO FOREVER TALK FOREVER 10:53, 11 November 2009 (UTC) ( INCORRECT: FOREVER )

(outdented reply )I'm ok with the donation page, Wales coud've said something abit more inspiring but thats besides the point... Now the banner, well, I've always thougt we should work to make Wikipedia a credible and at least generally trustworthy and usefull source of information, and I beleive thats the light in which we should try to cast ourselfs and the project. The current banner does not reflect this, its makes us look amateurish... Its something i'd expect from a a highschooll cheering squad. Can you imagine Britannica ever splashing "BRITANNICA FOREVER!" in a huge font all over their website? Acer (talk) 10:56, 11 November 2009 (UTC)

I've actually seen Britannica do much worse, including displaying an ad for extermination services next to their article about Auschwitz, but that's beside the point. I think switching from all-caps to regular case should address a major aesthetic concern at least, no?--Eloquence * 11:04, 11 November 2009 (UTC)

No. It's a combination of the phrase, the caps, the size. Here's an alternative: [9] Rd232 ^talk 11:07, 11 November 2009 (UTC)

cf Wikipedia:Village pump (proposals)#Abolish the silly headers. The failure to invite people to donate seems particularly bizarre. Rd232 ^talk 11:14, 11 November 2009 (UTC)

See, this is also something that happens every year: We ask for alternative suggestions, and we get tiny text banners that simply will not work. We know from past experience and metrics that font size directly correlates with donations. In fact, when we ran the Jimmy appeal last year, even adding a red border around the appeal made a significant difference. It's a simple fact of life that something that's appealing to you because it's not intrusive and resembles other day-to-day messages on the site will not work to actually raise the funds needed to keep your site running.--Eloquence * 11:11, 11 November 2009 (UTC)

Maybe so on size, but it's still a stupid slogan. Rd232 ^talk 11:14, 11 November 2009 (UTC)

I think that would help, but it still doesn't look all that professional. It looks like something one would have seen on a mid-90s Geocities site. What does "Wikipedia Forever" mean? Is it even a link? Not really clear on my browser. And a lot of the other slogans are even worse than this one. I'll tell you what, I'm going on the radio later this week to give Commons a bit of a plug, but I'm really considering whether I want to do that right now if that thing is the first thing that potential new visitors will see.

The other thing that concerns me, is can you even show me one person in the community, who isn't on the WMF payroll, who thought this was a good idea, either before or after it was implemented? Just one. I could understand going ahead if opinion was split, but this was one of those rare and beautiful moments where the entire community came together, and in one voice sang "No!". It takes a special sort of arrogance to ignore so many voices speaking in unison, and make the "Napoleon-invading-Russia-in-the-winter" sized blunder that this appears to be. Lankiveil ^{(speak to me)} 11:13, 11 November 2009 (UTC).

I've not seen people praising the banner (I'm not praising it myself - I'm waiting for more data), but above and in other places you'll see some people point out that the annual fundraiser outrage is part of our ritual every year. Choosing a design that doesn't resemble an ad banner but is simple plain text is a deliberate decision. Our plain text appeal from last year was the single biggest draw in terms of the number of donations. That's partially because of the appeal itself, but also (we believe) partially because choosing simple plain text designs makes it more likely to be noticed, rather than hitting the "banner blindness" part of your brain. Oftentimes, the parts of a message or banner that make you hate it are also the ones that make it work. Whether and to what extent this one works is something we'll learn in the next few hours.--Eloquence * 11:18, 11 November 2009 (UTC)

Something witty, catchy and not quite so intrusive would be good. This, however, sounds like something a 14 year old would graffiti onto a bus seat. Orderinchaos 11:19, 11 November 2009 (UTC)

(Cross-posted response to VPP thread MER-C 11:20, 11 November 2009 (UTC))

(outdented reply )Ok here's a suggestion, replace "WIKIPEDIA FOREVER" with "Fundraiser", you can keep the present size and the text format if you want, just make sure you keep the hide button for people who don't wnt to be disturbed. Or you can go with something witty and charming as the previous poster said, basically pretty much enything else is bound to be better than "WIKIPEDIA FOREVER" Acer (talk) 11:25, 11 November 2009 (UTC)

We're not going to replace "Wikipedia Forever" with "Fundraiser" :-). However, I'm in favor of collecting alternative slogans as well. If people don't disagree with the fundamental premise of the "Wikipedia Forever" campaign -- long term preservation and protection of Wikipedia -- what ways to express it would you find more acceptable?--Eloquence * 11:32, 11 November 2009 (UTC)

I kind of disagree that this is a message to focus on. I think the need to keep Wikipedia functioning well over the next year is a more immediate thing which people can relate to more easily. Forever is a long time, and frankly I'm not going to donate now so that Wikipedia will be slightly more likely to make it from year 500 to year 501. Rd232 ^talk 11:36, 11 November 2009 (UTC)

Again, if you want to focus on the longer term (if you're actually doing something in that area and isn't just hot air) you could have something like "Wikipedia 2020" (perhaps with optional "help us make it happen" or something). Not the childish "forever". Rd232 ^talk 11:40, 11 November 2009 (UTC)

Wikipedia: [logo] always there for you Fifelfoo (talk) 11:38, 11 November 2009 (UTC)

It's the way the message is presented rather than the message itself that is generating so much opposition. The general idea is that "WIKIPEDIA FOREVER" is simply inappropriate for an encyclopedia and makes us look like a joke. More detailed reasons can be found at the VP discussion if you'd take a moment to check it out. As for distinguishing between normal unhappiness and extraordinary unhappiness, how about extraordinary unhappiness being almost everyone opposing something? ;) But thank you for considering alternatives at least now; that's better than the "thank you for your opinion, but no thank you" we got earlier before this was launched. ≈ Chamal ^talk ¤ 11:47, 11 November 2009 (UTC)

I hear you, and I have read the VP discussion. I'm signing off from this one for now; I'll check in later when San Francisco is waking up (I'm currently in Germany) and will summarize some of the comments for internal circulation. Please continue to share your ideas both for banners and slogans at m:Fundraising 2009/Alternative banners. Right now I'm most likely to recommend a subdued variant.--Eloquence *

Thank you Mr. Möller for explaining that the English Wikipedia community no longer controls the English Wikipedia. — RockMFR 12:21, 11 November 2009 (UTC)

I see a very strong consensus here and at the village pump to remove the banner, at least temporarily. --MZMcBride (talk) 12:22, 11 November 2009 (UTC)

Can I remind everyone that the Common.css/js are far but temporary and can have effects of over a week due to caching ? —TheDJ (talk • contribs) 12:28, 11 November 2009 (UTC)

Is it different from other pages in that respect? Rd232 ^talk 12:37, 11 November 2009 (UTC)

Yes, as one of the few elements on Wikipedia, skin files are cached for up to 30 days on the client side. —TheDJ (talk • contribs) 12:44, 11 November 2009 (UTC)

I thought client-side caching could be overridden by the server. Does WP not do that to flush changes? Rd232 ^talk 12:53, 11 November 2009 (UTC)

No it cannot. Once you say to a browser "cache this file for 30 days", you cannot take that statement back, other then by changing the URL (a technique used by just a few of the skin files). There is a reason the todo list of this talk page has a header called "decaching", and for more information search for "cache" in the archives of this page and of MediaWiki_talk:Common.js —TheDJ (talk • contribs) 13:00, 11 November 2009 (UTC)

Fundraising banners have always been Foundation decisions. We are listening; please at least give San Francisco an opportunity to wake up before you're making changes to site-wide messaging. Having the fundraiser officially kicked off, with press releases, blog posts, and media coverage, and having the banner then suddenly removed, is far worse than tolerating a banner you don't like for a while longer. Again, it's very easy to turn this off in your preferences.--Eloquence * 12:27, 11 November 2009 (UTC)

Please stop saying "it's very easy to turn this off in your preferences", because we know that and it isn't the issue. We do not want others to see the message, because it's awful and embarrassing. Rd232 ^talk 12:36, 11 November 2009 (UTC)

It's not a matter of us "not liking" them, it's a matter of us finding them to be embarrassing and damaging to this project. user:J aka justen (talk) 12:37, 11 November 2009 (UTC)

(reply to eloquence) Except that you've been getting negative feedback ever since October and you still pushed ahead with it, pretty much ignoring everybody. So its not as simple as "tolerating it a while longer". Its making Wikipedia look bad. It needs to go. Acer (talk) 12:39, 11 November 2009 (UTC)

We've not ignored your feedback in October. It's part of the reasons why we have contingency banners (some ready, and some in development). But you'll need to give people in the office at least some time to assess the situation. I've already sent an internal heads-up email. We will review alternatives and try to come up with something that's more acceptable to the Wikipedia community.--Eloquence * 12:45, 11 November 2009 (UTC)

Yes you've ignored it. The feedback was that these are awful and needed to be replaced by something that made is not WikiPediaz For4ver!! Now they are up. I don't know how that's not ignoring feedback. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 13:39, 11 November 2009 (UTC)

Procedural inquiry: I can fully understand the reasons this would not be subject to community consensus, but is that actually documented in policy anywhere? Office actions are explained in policy, why isn't this exemption to consensus likewise spelled out? --Cybercobra (talk) 12:39, 11 November 2009 (UTC)

Isn't this an office action? (The thing that concerns me is not so much the fact the Foundation has chosen this banner, but the fact we're told they've spent a quarter of a million on doing so. Add this to the money they pay to selected developers for failing to develop the software, and I'm not greatly encouraged to given them any money. However we have to hope that some people will, or we won't be here.)--Kotniski (talk) 13:32, 11 November 2009 (UTC)

Eloquence's user page says that they clearly mark office actions. Fifelfoo (talk) 14:07, 11 November 2009 (UTC)

The first 9 hours of the 2008 fundraiser (0:00 to 9:00 UTC) had 682 donors raising $19022 (max donation $200). The first 9 hours of this fundraiser (5:00 to 14:00 UTC) has had approximately 515 donors raising $23300 (max donation $3000). It is too early to be drawing strong conclusions, but the very early averages are similar. Dragons flight (talk) 14:09, 11 November 2009 (UTC)

I'd read it differently, on the assumption that the amount donated has very little to do with the message, so we should ignore the dollar amounts. 515 donors is significantly less than 682. Rd232 ^talk 14:26, 11 November 2009 (UTC)

That may be true, and historically the average donation has been relatively invariant year over year (~$30). However, I wouldn't draw a conclusion for or against it without more data at this point. Every campaign has some launch difficulties, and I don't know how big an issue the timing is for example. Dragons flight (talk) 14:40, 11 November 2009 (UTC)

It's silly to draw comparisons before the first 24 hours are completed. Lara 15:28, 11 November 2009 (UTC)

Mm, I hadn't noticed they were launched at different times of day. So yes, need to compare whole days. Rd232 ^talk 16:33, 11 November 2009 (UTC)

Yes was just about to say the same thing. Particularly as 5:00 UTC is perhaps starting to get late enough in the night that fewer Americans may be visiting, and even for those that are, it may be something they decide to put off until tomorrow Nil Einne (talk) 16:37, 11 November 2009 (UTC)

Wikimedia should respect the wishes of those wishing to remove this message. I want it gone, not just rolled up to one line. I have no plans to ever donate money to your organization, so please let me remove your silly message. -Atmoz (talk) 17:16, 13 November 2009 (UTC)

There's a Browsing Gadget, under the Prefs->Gadget tab, allowing each registered user to suppress fundraising messages. Rd232 ^talk 17:36, 13 November 2009 (UTC)

Ta. One would think a link named "hide" would do that... -Atmoz (talk) 17:41, 13 November 2009 (UTC)

Disabled for now

I have been able to reproduce the bugs in IE6 and IE7. This is unacceptable and inexcusable, and I apologize on behalf of WMF for the bad start. I've disabled the banner through our CentralNotice feature.

With regard to the message itself, we're paying attention to what's being said here and elsewhere. We're going to, at minimum, go live again with a version that isn't all-caps, but we're also looking at the suggestions as well as our repository of existing banners. The theme of the fundraiser will continue to be preservation and long-term access, but we can do better in getting that message across.--Eloquence * 14:10, 11 November 2009 (UTC)

And I would like to reiterate that Common.css is not a place to make shortterm changes to the CSS. This CSS information will be cached by browsers potentially up to 30 days, so unless you want to affect things for more than 30 days, such changes should in general not be made here, even more so if we are talking about changes for just 1-2 days. —TheDJ (talk • contribs) 15:43, 11 November 2009 (UTC)

No, not really. Try putting some code in Common.css that blanks the Main Page and see if it takes 30 days for people to start noticing. 30 days is the maximum, but practical experience has taught us that a large number of browsers will reload and recache stylesheets every time the browser is restarted. While there are some people who won't get an updated copy, plenty of people will. That said, I would like to see a cleaner method for ensuring CSS changes are pushed faster, perhaps something similar to what MediaWiki:Edittools uses. --MZMcBride (talk) 19:19, 11 November 2009 (UTC)

"potentially up to 30 days" —TheDJ (talk • contribs) 19:31, 11 November 2009 (UTC)

(ec) Nice to see that talking to San Francisco (whoever that is) has led you to realise you've been completely stonewalling legitimate widespread community concerns all morning. Could we get an apology for your behaviour to go with the one for the banner? Even an admission that 'bugs' aren't the only reason this should never have happened? Modest Genius ^talk 15:45, 11 November 2009 (UTC)

Erik's been pretty reasonable, actually, replying to community messages. He's right that there is always a big community backlash against the hated banners every year (and as Dragon's flight pointed out somewhere, these aren't even the worst we've had). Nonetheless it does sound like they're going to take stock and reevaluate, so now is the time to be constructive. Remember that we do all want and need the fundraiser to be successful to keep Wikipedia up. -- phoebe / (talk to me) 17:17, 11 November 2009 (UTC) (who has been complaining about these banners for a couple of weeks now in various channels).

Agreed. The decision to turn the banners off in particular was a wise move. --MZMcBride (talk) 19:19, 11 November 2009 (UTC)

And the decision to turn them back on a few hours later? Modest Genius ^talk 14:36, 13 November 2009 (UTC)

It was made clear the main reason for turning them of was because they were buggy, not because people didn't like them. You presumed that there were other significant reasons but no one from the foundation or design team ever said there were (they said they may modify them givben the backlash, that's about all). The decision to turn them back on in a few hours when the problems were fixed was therefore entirely predicitable and expected and if you had diferent expectations it was entirely your own fault for ignoring what people actually said and presuming your assumptions were correct despite the lack of evidence. Nil Einne (talk) 01:53, 14 November 2009 (UTC)

So I assume from the lack of response that the answer is 'no'. Congratulations, I've completely lost what little respect I had left for the Foundation. Modest Genius ^talk 14:36, 13 November 2009 (UTC)

As from the lack of activity in the past few hours, it should be clear that the opposition to the current banners is significantly less than with the initial version. If you have no respect left for the foundation, you are welcome to start your own foundation+wikipediafork, or campaign in the next board elections or something. Now I would appreciate it, if this discussion about banners is no longer continued on the talk page of one of our CSS configuration pages. There are plenty more suitable venues at the moment. —TheDJ (talk • contribs) 14:48, 13 November 2009 (UTC)